Today, network service providers (NSPs) provide networks and communication services to facilitate communications, such as Voice over Internet Protocol (VoIP) calls. Millions of calls take place everyday. In most cases, the calls occur without any problems. For example, typically a caller calls another person, the call is successfully set up, the participants have a conversation, and the call is successfully torn down when one of the participants disconnects. However, not all calls occur without problems. For example, the call may not be set up or torn down properly. These and other problems can occur for any number of reasons. Failure of calls to complete can indicate network problems, such as device failure, incompatibility, or misconfiguration. As such, NSPs should identify problematic calls and determine the reason(s) for the problems in order to provide quality communication service. However, given the vast number of calls attempted everyday, and the network complexities involved, call problem identification and analysis can be a daunting task.
NSPs have traditionally dealt with call problem identification in different ways. Sometimes NSPs do not monitor for call success or failure, but merely react to problems when they are notified of them. For example, subscriber complaints may prompt the NSP to identify and fix problems. Merely reacting to subscriber complaints is clearly not a prudent business model for providing quality communication service. As such, most NSPs would prefer to monitor for problems and fix the problems before they impact future calls. Unfortunately, conventional approaches have been inefficient, inflexible, and/or incomplete.
Another significant challenge to network problem monitoring and identification relates to physical changes in the network. This can include situations in which one NSP begins interfacing with another NSP or when an NSP switches network architecture. Typically when two NSPs interface their networks, they perform “interoperability” testing to ensure that the two networks operate properly together. Interoperability testing can be a very complicated task, given the complexity of the networks. After interoperability testing is complete, and the networks are working properly together, if one NSP switches to a different network architecture, this may necessitate more interoperability testing by interfacing NSPs. However, the NSP that has not switched network architecture will not want to invest the time and expense for additional interoperability testing merely to accommodate changes in the other NSP's network.
Another problem relates to extensibility in some communication or messaging protocols. For example, Session Initiation Protocol (SIP), which is often used to set up calls over VoIP networks, allows for variation in the definitions of message format and parameters. In SIP, for example, an NSP can define different message headers. As a result, multiple different types of messages may be communicated over the network. Some of the message definitions may result in failed calls. Message variation problems can be particularly relevant when switching to a new network architecture. Messages that worked on the first architecture may not work on a new architecture. Conventional systems cannot quickly or efficiently identify network problems that arise due, at least in part, to message variations.